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Support for Multiple Clock Rates in an RTP Session 


Abstract 
This document clarifies the RTP specification regarding the use of 
different clock rates in an RTP session. It also provides guidance 
on how legacy RTP implementations that use multiple clock rates can 
interoperate with RTP implementations that use the algorithm 
described in this document. It updates RFC 3550. 
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This document is a product of the Internet Engineering Task Force 
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Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
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1. Introduction 
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The clock rate is a parameter of the payload format as identified in 


RTP 


and RTCP (RTP Control Protocol) 


by the payload type value. It is 


often defined as being the same as the sampling rate but that is not 
always the case (see, for example, the G722 and MPA audio codecs 
[RFC3551]). 


An RTP sender can switch between different payloads during the 
lifetime of an RTP session and because clock rates are defined by 


payload format, 


during an RTP session. Schulzrinne, 
multiple clock rates as one of the reasons to not use different 


payloads on the same Synchronization Source 


it is possible that the clock rate will also vary 
lists using 


Unfortunately, 


this advice has not always been followed and some RTP implementations 
change the payload in the same SSRC, 


use different clock rates. 
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This creates three problems: 
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o The method used to calculate the RTP timestamp field in an RTP 
packet is underspecified. 

o When the same SSRC is used for different clock rates, it is 
difficult to know what clock rate was used for the RTP timestamp 
field in an RTCP Sender Report (SR) packet. 

o When the same SSRC is used for different clock rates, it is 


difficult to know what clock rate was used for the interarrival 


jitter field in an RTCP Receiver Report 


(RR) 


p 


acket. 


Table 1 contains a non-exhaustive list of fields in RTCP packets that 


uses a clock rate as a unit: 


+ P SN pe ee o o RN 
| Field name 


RTP timestamp 
Interarrival jitter 
min jitter 

max jitter 

mean jitter 

dev jitter 
Interarrival jitter 
RTP timestamp 
Jitter 


Median jitter 


Summary Block 


Summary Block 
Summary Block 
Summary Block 
IJ 

SMPTETC 
RSI Jitter Block 


RSI Stats Block 


Table 1 


Reference 
[RFC3550] 
[RFC3550] 
[RFC3611] 
[RFC3611] 
[RFC3611] 
[RFC3611] 
[RFC5450] 
[RFC5484] 


[RFC5760] 


[RFC5760] 


--+ 


Section 3 and its subsections try to list all of the algorithms known 
to be used in existing RTP implementations at the time of writing. 
These sections are not normative. 


Section 4 and its subsections recommend a unigue algorithm that 


modifies RFC 3550. 
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2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


In addition, this document uses the following terms: 


Clock rate The multiplier used to convert from a wallclock value 
in seconds to an equivalent RTP timestamp value 
(without the fixed random offset). Note that RFC 3550 
uses various terms like "clock frequency", "media 
clock rate", "timestamp unit", "timestamp frequency", 
and "RTP timestamp clock rate" as synonymous to clock 
rate. 


RTP Sender A logical network element that sends RTP packets, 
sends RTCP SR packets, and receives RTCP reception 
report blocks. 

RTP Receiver A logical network element that receives RIP packets, 
receives RTCP SR packets, and sends RTCP reception 
report blocks. 


3. Legacy RTP 


The following sections describe the various ways in which legacy RTP 


implementations behave when multiple clock rates are used. "Legacy 
RTP" refers to RFC 3550 without the modifications introduced by this 
document. 


3.1. Different SSRC 


One way of managing multiple clock rates is to use a different SSRC 
for each different clock rate, as in this case there is no ambiguity 
on the clock rate used by fields in the RTCP packets. This method 
also seems to be the original intent of RTP as can be deduced from 
points 2 and 3 of Section 5.2 of RFC 3550. 


On the other hand, changing the SSRC can be a problem for some 
implementations designed to work only with unicast IP addresses, 
where having multiple SSRCs is considered a corner case. Lip 
synchronization can also be a problem in the interval between the 
beginning of the new stream and the first RTCP SR packet. 
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3.2. Same SSRC 


The simplest way to manage multiple clock rates is to use the same 
SSRC for all of the payload types regardless of the clock rates. 


Unfortunately, there is no clear definition on how the RTP timestamp 
should be calculated in this case. The following subsections present 
the algorithms currently in use. 


3.2.1. Monotonic Timestamps 


This method of calculating the RTP timestamp ensures that the value 
increases monotonically. The formula used by this method is as 
follows: 


timestamp = previous_timestamp 
+ (current capture time - previous capture time) 
* current clock rate 


The problem with this method is that the jitter calculation on the 
receiving side gives an invalid result during the transition between 
two clock rates, as shown in Table 2 (Appendix A). The capture and 
arrival time are measured in seconds, starting at the beginning of 
the capture of the first packet; clock rate is measured in Hz; the 
RTP timestamp does not include the random offset; and the transit, 
jitter, and average jitter use the clock rate as a unit. 


Calculating the correct transit time on the receiving side can be 
done by using the following formulas: 


1. current capture time = (current timestamp - previous timestamp) / 
current clock rate + previous capture time 


2. transit = current clock rate * (arrival time — 
current capture time) 


3. previous capture time = current capture time 
The main problem with this method, in addition to the fact that the 
jitter calculation described in RFC 3550 cannot be used, is that it 


is dependent on the previous RTP packets, which can be reordered or 
lost in the network. 
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3.2.2. Non-monotonic Timestamps 


An alternate way of generating the RTP timestamps is to use the 
following formula: 


timestamp = capture_time * clock_rate 


With this formula, the jitter calculation is correct but the RTP 
timestamp values are no longer increasing monotonically as shown in 
Table 3 (Appendix A). RFC 3550 states that "[t]he sampling instant 
MUST be derived from a clock that increments monotonically . . ." 
but it does not say that the RTP timestamp must increment 
monotonically. 


r 


The advantage with this method is that it works with the jitter 
calculation described in RFC 3550, as long as the correct clock rates 
are used. It seems that this is what most implementations are using 
(based on a survey done at SIPit26 and on a survey of open source 
implementations, see Appendix C). 


4. Recommendations 


The following subsections describe behavioral recommendations for RTP 
senders (with and without RTCP) and RTP receivers. 


4.1. RTP Sender (with RTCP) 


An RTP Sender with RTCP turned on MUST use a different SSRC for each 
different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST 
be used if the clock rate switches back to a value already seen in 
the RTP stream. 


To accelerate lip synchronization, the next compound RTCP packet sent 
by the RTP sender MUST contain multiple SR packets, the first one 
containing the mapping for the current clock rate and the subsequent 
SR packet (s) containing the mapping for the other clock rates seen 
during the last period. 


The RTP extension defined by Perkins & Schierl [RFC6051] MAY be used 
to accelerate the synchronization. 


4.2. RTP Sender (without RTCP) 


An RTP Sender with RTCP turned off (i.e., having set the RTP Sender 
and RTP Receiver bandwidth modifiers [RFC3556] to 0) SHOULD use a 
different SSRC for each different clock rate but MAY use different 
clock rates on the same SSRC as long as the RTP timestamp is 
calculated as explained below: 


Petit-Huguenin & Zorn Standards Track [Page 6] 


RFC 7160 Multiple Clock Rates April 2014 


Each time the clock rate changes, the start_offset and capture_start 
values are calculated with the following formulas: 


start offset += (capture time - capture start) * previous clock rate 
capture start — capture time 


For the first RTP packet, the values are initialized with the 
following values: 


start offset — random initial offset 
capture start — capture time 


After eventually updating these values, the RTP timestamp is 
calculated with the following formula: 


timestamp = (capture time - capture start) * clock rate 
+ start offset 


Note that in all the formulas, capture start is the first instant 
that the new timestamp rate is used. The output of the above method 
is exemplified in Table 4 (Appendix A). 


4.3. RTP Receiver 


An RTP Receiver MUST calculate the jitter using the following 
formula: 


D(i,j) = (arrival time j * clock rate i — timestamp j) 
- (arrival time i * clock rate i — timestamp i) 


An RTP Receiver MUST be able to handle a compound RTCP packet with 
multiple SR packets. 


5. Security Considerations 


When the algorithm described in Section 4.1 is used, the security 
considerations described in RFC 3550 apply. 


The algorithm described in Section 4.2 is new and so its security 
properties were not considered in RFC 3550. Although the RTP 
timestamp is initialized with a random value like before, the 
timestamp value depends on the current and previous clock rates, this 
may or may not introduce a security vulnerability in the protocol. 
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Appendix A. Example Values 


The following tables illustrate the timestamp and jitter values 
produced when the various methods discussed in the text are used. 


The values shown are purely exemplary, illustrative, and non- 


normative. 
+------- +------- +-—————————— +-———————— +-————————— +--——————— +-—————————— + 
| Capt | Clock | RTP | Arrival | Transit | Jitter | Average | 
| time | rate | timestamp | time | | | jitter | 
k +-—2—5-2-— 1-—-———2—2—— 12-22—5———2 F 1-———-22— +———-—2—5—5 + 
| o | 8000 | 0 | gel | 800 | | 
| | | | | | | | 
| 0.02 | 8000 | 160 | 2012 | 800 | o | o 
| 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 
| | | | | | | | 
| 0.06 | 8000 | 480 | 0.16 | 800 | o | o 
| | | | | | | | 
| 0.08 | 16000 | 800 | 0.18 | 2080 | 480 | 30 
| 0.1 | 16000 | 1120 | 0.2 | 2080 | 0 | 28 
| | | | | | | | 
| 0.12 | 16000 | 1440 |, 0522 | 2080 | o | 26 
| | | | | | | | 
| 0.14 | 8000 | 1600 | 0.24 | 320 | 720 | 40 

0.16 8000 1760 0.26 320 0 65 
+-——————— +--—————— +-—————————— +-———————— +-———————— +--——————— +-—————————— + 


Table 2: Monotonic Timestamps 
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1-———-2—— +-2-—-2— o fo 555 E otete Fm 555553 12-—0—225—— + 
| Capt | Clock | RTP | Arrival | Transit | Jitter | Average | 
| time | rate | timestamp | time | | | jitter | 
+------- +------- +-—————————— +--———————— +-———————— +--——————— +-—————————— + 
| o | 8000 | 0 | O.1 | 800 | | 

| | | | | | | | 
| 0.02 | 8000 | 160 | 0.12 | 800 | o | o 

| | | | | | | | 
| 0.04 | 8000 | 320 | 0.14 | 800 | 0 | 0 

| 0.06 | 8000 | 480 | 0.16 | 800 | o | 

| | | | | | | | 
| 0.08 | 16000 | 640 | 0.18 | 1600 | o | o 

| | | | | | | | 
| O.1 | 16000 | 960 | 0.2 | 1600 | o | o 

| 0.12 | 16000 | 1280 | 0.22 | 1600 | 0 | 0 

| | | | | | | | 
| 0.14 | 8000 | 1600 | 0.24 | 320 | o | o 

| | | | | | | | 
| 0.16 | 8000 | 1760 | 0.26 | 320 | o | o 

+------- +------- +----------- +--------- +-———————— +--——————— +-————————— + 


Table 4: Recommended Method for RTP Sender (without RTCP) 
Appendix B. Using a Fixed Clock Rate 
An alternate way of fixing the issue with using multiple clock rates 
was proposed by Wenger and Perkins [AVI-VAR-RATE]. This document 
proposed to define a unified clock rate, but the proposal was 
rejected at IETF 61. 
Appendix C. Behavior of Legacy Implementations 
C.I Libcertp 2.02 


This library uses the formula described in Section 3.2.2. 


Note that this library uses gettimeofday(2) which is not guaranteed 
to increment monotonically (e.g., when the clock is adjusted by NTP). 


C.2. libmediastreamer0 2.6.0 


This library (which uses the oRTP library) uses the formula described 
in Section 3.2.2. 


Note that in some environments this library uses gettimeofday (2), 
which is not guaranteed to increment monotonically. 
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C.3. libpjmedia 1.0 
This library uses the formula described in Section 3.2.2. 
C.4. Android RTP Stack 4.0.3 


This library changes the SSRC each time the format changes, as 
described in Section 3.1. 
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